Cream of the Crop 20/Cream of the Crop 20 (Terry Blount) (1996).iso/os2/lxlt115.zip/LXLITE.ENG

Text File | 1996-06-19 | 28KB | 532 lines

              ──────────────────────────────────────────────
               LX lite - an compressor for OS/2 executables
              ──────────────────────────────────────────────

                                 Dedication: To my little daughter Alice,
                                             born 12 Feb, 1996 at 03:45.

  1. Distribution
  ───────────────
   This program is freeware. This mean that you can distribute it in any way,
 except  for  commercial use. Commercial use is allowed ONLY with my personal
 permission.  To  contact me see the the last section in this file. This also
 means  that  you  have  NO  guaranties that it will perform exactly what YOU
 need. I cannot carry any responsability for any damages, lost of profit etc.
 caused  by  use  or  inability to use this program.
   However,  you CAN use it to enhance any, even commercial, product. This is
 not  for  YOUR benefit but rather for benefit of poor users who are BORED of
 the big size of executables.
   The  program is written exclusively in Virtual Pascal, beta 3, with use of
 its  built-in  32-bit  assembler.  This is an excellent language which takes
 full  advantages  of  OS/2`s possibilities, is BorlandPascal compatible, and
 have  a  powerful  built-in optimizer. If you want the lxLite`s source code,
 please  mail  me,  but  you have to tell me WHY do you need it, to avoid the
 people which likes to re-sell other`s programs under their name.

  2. Introduction
  ───────────────
   I  think  all  of  us  are  really  bored  of  the  big  size  and reduced
 functionality  of  all  those  modern  executables written to run under OS/2
 (windos  too).  I  don`t  understand  why  they  are  so  big,  because most
 compilers,  even  IBM  CSet  generate a modest size code. For a widely known
 example  let`s  take  MultiMaint.  What  a complex task it performs that its
 executable  occupies  more  that  700K?  I  don`t  understand. Moreover, WHY
 duplicate  (and  triplicate)  almost  the same executable as it does (I mean
 MultiSafe  and  IniMaint  which  comes along with MultiMaint). It performs a
 nice  work,  but it is TOO big for the task it acomplishes. OS/2 kernel have
 the  same  size.  I  cannot  afford such a large pile of shit on my HD, so I
 killed MultiMaint & C°. :`-(. Too bad for its author.
   Here is a workaround for this. You can just pack the executable so it will
 be  twice  smaller  and  still perform the same task. Alas, it will grab the
 same amount of memory as original executable does - this is the fault of the
 program`s author.
   As  far  as  I know there is only one program which does the same - REPACK
 from  IBM  (EWS?).  But  compared  to lxLite it gives larger files using the
 same algorithm. For example, COURIER.FON from OS/2 v8.192 it compresses into
 44K  and  lxLite  into  34K.  Feel  the  difference.  BTW,  LINK386+Resource
 Compiler  compiles  COURIER.FON  also into 44K-size file. This make me think
 that they use the same common library.
   I  packed  ALL  my executables (incuding but not limiting to ?:\os2\*.exe,
 ?:\os2\dll\*.*  and  ?:\os2\dll\ibmnull;laserjet)  and  my  system  is stiil
 working  fine  :-)  One  of lxLite users (Pavel Roskin) observed that lxLite
 packs  even  os2krnl :-) This is a very nice feature to create a SINGLE OS/2
 boot diskette.

  3. Features
  ───────────
   lxLite  compresses  the files in the same way as LINK386 does. There is NO
 way  of  implementing a executable packing method other than those two which
 Warp  uses  (or  the only for 2.x). So, here is a brief description of those
 two algorithmhs:

   1.  Run-length packing. This is generally the same method that Microsoft C
 for  DOS uses. It gives VERY bad results because the structure of executable
 files  aren`t  suited  for that kind of packing. For example, PCX files uses
 approximatively the same packing method.

   2.  Kinda Lempel-Ziv algorithm. Lempel-Ziv is the same method which almost
 all  DOS  executables  packers  use  - LZEXE, PKLITE, PGMPAK etc. The method
 standartized  for  OS/2  executable  files is not the most effective (IMHO).
 Other  thing  is  that OS/2 executable have a different loading algorithm in
 contrast to DOS executables - parts of OS/2 executables are loaded only when
 they  are  needed.  So,  Lempel-Ziv  dictionary  cannot cross the bound of a
 single page (4096 bytes). Because of this, it gives not such good results as
 it can.

   lxLite  can  use any of these two methods either for packing or unpacking.
 Generally  the second gives best compression rates, but may be (?) there are
 some  files  on which first will work better. Because of this the default is
 to  try  to pack page using both methods and then choose the smaller result.
 lxLite can be used as well for unpacking the files that previously have been
 packed - either by lxLite, LINK386 or REPACK from IBM.

   What  kind  of  files  you  can  compress?  The  LX  format is used almost
 everywhere in OS/2: almost everything is in LX format. So, you don`t have to
 limit  only  to  .EXE files: you can pack .DLL, .PDR, .QPR, .DRV, .FON, .SYS
 (Virtual  Device Drivers (VDDs) in \OS2\MDOS) as well. You can run lxLite on
 virtually  any  file:  if it is not in Linear Executable (LX) format it will
 refuse to process it.

   You can also consider compressing your entire \OS2\*\ directory structure,
 it  will  give you a lot of extra space and absolutely no overhead! The time
 spent  for  decompressing  executables is recovered by the time which system
 does  not  spend  for  reading  the  executable  from  HD  because it`s much
 smaller!  So, reboot from stand-alone OS/2 diskettes (you can boot from OS/2
 installation  diskettes  (first  two)  then  press F3), then change to drive
 where your OS/2 is and type
  \[path]\lxLite os2\*.exe os2\dll\*.* os2\dll\ibmnull\*.drv
   and  so  on.  Also  you  can compress now the executables which are run at
 system   startup,  because  when  they  are  run  you  cannot  modify  their
 executables and DLL`s.

   lxLite  version 1.00 and above can replace executable modules even if they
 are  currently  in use. In this case it will warn you that module is already
 in  use by another process, and will propose you either to replace it by its
 packed  version  or  either  to  skip  this module. Choose at your wish, but
 keep  in  mind  that  the  modules you have replaced are kept now (their old
 versions)  in  memory,  so they eat up your swapfile space. Better reboot as
 soon as you have this opportunity.

   Versions  above  1.00 are supplied in two different executables: one named
 lxLite.exe  is  the  usual  version  for OS/2 v2.99, Warp and aboves. Other,
 named  lxLite2x.exe  is meant for use in old versions of OS/2 (i.e. 2.x, NOT
 1.x because 1.x doesn`t have the LX format). Delete it if you`re a OS/2 Warp
 user.

   Version 1.1.0 and above detects executables which contains some data after
 the  LX  structure  itself  (i.e.  what`s  called  in DOS overlay data). For
 example  Watcom`s  binded executables (such as WCC.EXE versions >= 10.0) and
 Watcom  Visual  Rexx  executables  have  such structure. In this case lxLite
 shows  an warning message and asks for confirmation whenever you really want
 to  pack  such  executable.  It  is STRONGLY recommended that you backup the
 executable  in  question  before trying to do it because it is VERY possible
 that  it will become non-functional if something gets changed in it (because
 lxLite  does  not change any of possible pointers in data binded to LX as in
 VREXX executables).


  4. Options
  ──────────
   There are alot of options in lxLite. I simply like options :-) So, you can
 configure almost anything in lxLite. Moreover, to protect the user from need
 of writing the same options lxLite support multiple configurations which are
 kept  in  a  single  file.  lxLite  comes  with  some example configurations
 (`factory defaults`) which are listed below:
 ─────────────────────────────────────────────────────────────────────────